1. Field of Invention
The present invention relates generally computer-aided design (CAD) tools such as Electronic Design Automation (EDA) tools, hardware description languages, and logic synthesis for electronic circuit design.
2. Description of Related Art
Modern digital design of complex circuits and systems, which can contain millions of interconnected gates, involves a number of techniques for manageable design. Tools using CAD, EDA, hardware description languages (HDL), logic synthesis, hierarchy design, and xe2x80x9cdivide and conquerxe2x80x9d strategies such as top-down design are employed.
A hardware description language (HDL) representation of a circuit is a representation of a circuit in text rather than graphically, enabling a more uniform, portable representation of the circuit, one that can be manipulated by a computer program. Currently, Verilog and VHDL are two major standards of HDLs. HDL may be stylized into xe2x80x9cstructuralxe2x80x9d (e.g. at the gate-level), xe2x80x9cbehavioralxe2x80x9d or xe2x80x9cdataflowxe2x80x9d (typically at the higher level description of a circuit), or any combination of the above. HDL representations are used in logic synthesis, the conversion of a high-level electronic circuit description into a list of logic gates and their interconnections, called the xe2x80x9cnetlistxe2x80x9d.
An HDL description of a system can be written at an intermediate level language referred to as a Register Transfer Level (RTL). A subset of RTL that is used by logic synthesis tools (such as Synopsys"" DesignCompiler and Cadence""s Ambit) is known as xe2x80x9csynthesizable RTLxe2x80x9d. A logic synthesis tool with a library of components can convert a RTL description into an interconnection of primitive components that implements the circuit, subject to any specified constraints, such as timing, speed, power consumption and area constraints. Typically, these constraints are specified by the designer of the circuit. The output of the logic synthesis tool, after an optimization process referred to as technology mapping, is a so-called netlist of interconnected storage elements, gates, and other functional blocks (note the term xe2x80x9cnetxe2x80x9d is also a keyword in Verilog, and represents a data type comprising a physical connection between structural elements). The netlist output serves as input to physical design tools that physically place the logic elements and route the interconnections between them to produce a manufacturing circuit layout. When programmable parts are employed, such as field-programmable gate arrays, binary information is produced by design tools to program the logic within the parts.
Hierarchy design involves following an inverted tree in design, with the top-level design of the circuit at the root and more increasingly specific levels of detail at the branches and leaves below. Functional blocks (or modules, with the term xe2x80x9cmodulexe2x80x9d also a keyword in Verilog HDL) are employed at the upper echelons of the tree, while primitive blocks (such as NAND gates) are employed at the lower echelons. In theory the design process is xe2x80x9ctop downxe2x80x9d, where the circuit function is specified by text, with constraints on cost, performance and reliability, and then the circuit is designed by repeatedly dividing it into blocks as necessary. In practice, in order to obtain reusability and to make maximum use of predefined modules, it is often necessary to perform portions of the design bottom up. In addition, bottom up design is sometimes necessary to eliminate violations of constraints in a preliminary specification. When a preliminary original design of a circuit has to modified or changed it is termed an engineering change order (ECO), and the subsequently modified or changed original design of the circuit may be termed a modified circuit, post-layout annotated circuit, post-layout circuit, or ECO circuit.
The term ECO (Engineering Change Order) is commonly used to represent a variety of concepts. An ECO may refer to a functional change, in which the functionality of the circuit has changed and is no longer logically equivalent to the pre-ECO (original) design. An ECO may also refer to a non-functional change, in which the new design remains functionally equivalent to the original design. Typically non-functional type of changes are made in order to change the timing behavior of the circuit, or to accommodate manufacturability issues encountered during layout (e.g., overloaded cells that result in signal ramp times that are outside the characterized range of operation of the cell). Non-functional changes in an ECO may be introduced by the designer, the layout engineer, or by CAD tools during physical implementation (layout).
There are several categories of non-functional ECO changes in a circuit: physical-only transformations and gate-level transformations. Physical-only non-functional ECO changes are not reflected in the gate-level netlist. Examples of non-functional physical-only ECO changes are changing the placement of a cell, re-implementing the routing of a signal/net, or modifying the physical location of physical pins. A gate-level non-functional ECO transformation is a type of change that may change the gate level netlist by the introduction of new cells, swapping of cells for different drive strength logically-equivalent cells, or local logic restructuring (i.e., re-synthesis of a specific logic cone to create an alternative gate-level representation).
ECO changes submitted after a significant amount of physical implementation has occurred are very problematic, given today""s commercial Electronic Design Automation (EDA) tool offering. Since the physical realization (placement, routing and physical optimization) of a design for large circuits may involve months of engineering effort and many resources (both software and hardware), preserving as much of the prior physical implementation as possible is of paramount importance when incorporating logic changes into a design once physical implementation has begun. While today""s physical design tools offer some capabilities for dealing with ECOs, they are not capable of preserving netlist changes that have been introduced during layout. Specifically, today""s physical design tools allow comparison of the netlist representation inside of the tool""s database with an external gate-level netlist. As a result of this comparison, the physical design tool identifies changes that must be made to the database (i.e., deletion/addition of cells and deletion/addition of connections between the cells) to make the database consistent with the external netlist. For ECOs that are implemented manually at the gate-level by the designer (as opposed to modifying the source RTL and creating a new gate-level netlist through logic synthesis), this mechanism works fine as long as the modifications are made to the post-layout netlist from the previous iteration of the layout.
However, this approach to introducing ECOs to a design has several significant drawbacks:
(1) The source description of the design is generally considered the HDL/RTL, not the gate-level netlist. Maintaining an accurate representation of the design in RTL is critical to ensure that future generations of a design can leverage the current design description (i.e., migration from one technology to another, specialization/generalization of a design, integration of the design into a larger design). Functional modifications made at the gate-level cannot be easily propagated to the new generations of a design.
(2) If the ECO is manually implemented in the gate-level netlist, the gate-level netlist is no longer guaranteed to be functionally equivalent to the source RTL (since it was not technically feasible to manually implement an equivalent change at the RTL level, this technically feasible to manually implement an equivalent change at the RTL level, this is often extremely difficult to do, and generally requires use of formal verification tools to ensure that the changes are truly equivalent.
(3) For large-scale functional changes to functional blocks/modules, it may be impractical to manually make the changes at the gate-level. What would require relatively minor change to the RTL could result in massive changes necessary at the gate-level. Under these circumstances, the designer is generally forced to throw away the previous layout, even if the changes are isolated to only a small portion (functional block) of the design.
Therefore, there is a need for a way to make functional changes to a design at the RTL level, while providing a mechanism to preserve as much of the existing physical implementation as possible.
A partial solution to this problem was provided with the introduction of Synopsys"" ECO Compiler tool. It allowed a designer to preserve portions of a gate-level implementation for a design that had been re-synthesized from a modified RTL. It took the original RTL and the corresponding gate-level netlist generated via logic synthesis, and a new (modified) RTL and the corresponding gate-level netlist generated via logic synthesis, and created an output gate-level netlist that preserved all the gate-level implementation for functional blocks that did not change at the RTL level. This was necessary because even though the RTL description for these blocks may not have changed going into re-synthesis, there is no guarantee that successive runs of a logic synthesis tool will result in identical gate-level implementations for a given set of RTL code. With Synopsys"" ECO Compiler, the idea was that the output gate-level netlist would only have new gate-level representations for those functional blocks where the RTL had changed, and the rest of the blocks (modules) would use the original gate-level implementation.
Unfortunately, Synopsys"" ECO Compiler did not account for the fact that once a design goes into the physical design process, the gate-level netlist changes. While the changes introduced by the physical design tools are guaranteed to preserve functional equivalence at that design level, they can significantly modify the interfaces (input, output, and inout ports) for intermediate hierarchical modules in the design. This results in false mis-compares for virtually every functional block in the design for real deep sub-micron designs where clock tree synthesis, repeater insertion and significant physical optimization are required to realize the design. Alternatively, ECO Compiler could be run using the pre-layout gate-level netlist originally produced by the logic synthesis tools, meaning that all the changes made by the physical design tools would be lost.
The essence of the problem is the post-layout gate-level netlist from the current layout (which incorporates all the changes made by the physical design tools) cannot serve as the xe2x80x9coriginalxe2x80x9d gate-level netlist for Synopsys"" ECO Compiler because ECO Compiler cannot establish the correspondence between the xe2x80x9coriginalxe2x80x9d RTL modules and the post-layout gate-level modules due to differences in the module interfaces (ports). In fact, even full-fledged modern formal verification tools have difficulty dealing with this problem. Instead of trying to resolve these types of mismatches at each level of logic hierarchy, today""s formal verification tools xe2x80x9cflattenxe2x80x9d the design hierarchy when intermediate module interfaces do not match with the xe2x80x9creferencexe2x80x9d design in order to check across hierarchical boundaries. Since the whole ECO Compiler solution hinges on proper identification of hierarchical modules that have not changed, flattening the logic hierarchy undermines the ability to accomplish this, and therefore incorporating formal verification techniques into ECO Compiler would still not address the problem.
However, if there were a way to create an RTL description that is consistent with the post-layout gate-level netlist module structure, then we could utilize a tool like ECO Compiler in conjunction with existing physical design tools to preserve the layout for portions of the design where no functional changes are required at the RTL level.
Another problem arising from changes introduced by physical design tools relates to the management of design constraints (e.g., timing constraints) between pre- and post-layout design representations. Constraints, which may be created in the context of an HDL description, are sometimes difficult to interpret at the gate-level hierarchy, which may have a different interface (i.e., a module port) for a module/block than the higher hierarchy RTL description of the same circuit. Thus tools must translate constraints so they can be shared between the gate-level and RTL descriptions of the design, and to facilitate subsequent ECOs introduced at the RTL level. If the RTL is not modified to match the gate-level module descriptions, then a separate set of constraints must be maintained at the gate level and the RTL level, and there is currently no tool to aid the designer in ensuring correspondence between the two different sets of constraints.
As the complexity of designs increase, designers employ a plurality of disparate tools to deal with the design of electronic circuits, in particular dealing with timing, such as employing timing optimization tools, such as Avant!""s Apollo(trademark) or Cadence""s Silicon Ensemble(trademark), and ECO synthesis tools, such as by Synopsys"" ECO Compiler(trademark). One of the aspects of the present invention is to realize that these tools can be combined with a single comprehensive tool that can modify the design netlist without the need for a plurality of such tools and without the need for wasteful time consuming operations or excessive manual intervention. A further aspect of the present invention is to use it as a xe2x80x9cgluexe2x80x9d software tool that sits between the existing software tools, to allow these tools to work together to facilitate incorporation of logic changes (functional ECOs) into an existing physical implementation, without restart the layout process. In addition, application of the principals described herein with either implementation, will ensure correspondence between the design description and constraints at the different levels of abstraction (HDL/RTL versus gate-level).
An aspect of the present invention is to provide an electronic design automation (EDA) software tool to facilitate gate-level timing optimization and provide a seamless interface for Engineering Change Orders (ECO) once physical design implementation (layout) has started.
Another aspect of the present invention is to provide for a management tool for netlists, and to create an annotated RTL netlist that matches the hierarchical structure (i.e., module interfaces) for all intermediate levels of logic hierarchy.
Yet another aspect of the invention is to provide for automatic and semi-automatic modification of constraints, such as timing constraints, in a post-layout circuit, given a pre-layout circuit and constraints related to the pre-layout circuit.
The above described features and many other features and attendant advantages of the present invention will become apparent from a consideration of the following detailed description when considered in conjunction with the accompanying drawings.